oh, need to consider skin reload...

edit: Done.

Extending this to WMainMenuBar, as done in #1746, is certainly possibly.

Done.

We could add dummy shortcuts (empty) to all currently unmapped menubar actions so users can add shortcuts themselves.
(i.e. add ConfigKeys to menubar and all *.kbd.cfg files)

Nothing that holds up this PR though.

This one has a conflict now. Can we remove the 2.5-beta milestone?

Sure, assigned it to 2.5 for now because I think this is a bugfix, see #9814
It can either slip in during the beta period (it's already working without issues), or later.

Set to draft because I've just rebased this and am about to tweak it considering @cr7pt0gr4ph7's suggestions.

Thanks for taking the time to review!

Spelling of "chnanged" in the commit message.

Yeah, that happens when I work in bright sunlight...

Oh sorry, I did a rebase instead of merging main.

some thoughts on the general tooltip update approach used here and performance:

With the current implementatoin kbd mapppings are (re)loaded

• on startup
• when kbd shortcuts are toggled on, and
• when the mapping file has been edited

so I think a tiny performance hit (GUI thread) in these non-critical situations is an acceptable tradeoff for having the GUI reflect the complete kbd mapping (all possible poti sub-controls) immediatly, even if it's just for double-checking that the mapping has been applied as expected.

The current method is:

• for each control widget (button, knob, ..) the skin parser collects ConfigKeys for the from-widget connections, optionally creates the sub-control strings to be displayed in the tooltip
  ('up', 'down', 'up small', 'down small' for knobs and sliders, 'activate', 'clear' etc. for Hotcue buttons)
• this CfgKey/string list is stored in each WBaseWidget
• each widget is registered in KeyboardEventFilter (~1600 for LateNight 16 Samplers)
• KeyboardEventFilter loads the kbd mapping file
• iterate over all registered widgets, check if the controls are in the kbd mapping
  • yes: (re)create kbd tooltip strings
  • no: clear kbd tooltip string
  • push string to widget, (re)construct tooltip
• similar method for menubar actions

The downside:
all widgets are updated even if just one shortcut has been changed.

So I tried another approach, hoping that it would it be faster (in total, ie. load mapping file, check shortcuts, update widgets):

• reload kbd mapping
• compare last/new mapping, collect changed/added/removed shortcuts
• collect affected widgets
• update affected widgets

I had to implement the compare method and store more data in KeyboardEventFilter, and it turned out that this did not shorten the total time to the extent that it justifies the additional complexity (and potential errors/inconsistency), given that shortcuts are evaluated rarely.
(current method: ~6-7ms in total, alternative: ~5-6ms, measured when changing one shortcut)
I can provide the commit if someone is interested.

some thoughts on the general tooltip update approach used here and performance:

With the current implementatoin kbd mapppings are (re)loaded

• on startup
• when kbd shortcuts are toggled on, and
• when the mapping file has been edited

so I think a tiny performance hit (GUI thread) in these non-critical situations is an acceptable tradeoff for having the GUI reflect the complete kbd mapping (all possible poti sub-controls) immediatly, even if it's just for double-checking that the mapping has been applied as expected.

The current method is:

• for each control widget (button, knob, ..) the skin parser collects ConfigKeys for the from-widget connections, optionally creates the sub-control strings to be displayed in the tooltip
  ('up', 'down', 'up small', 'down small' for knobs and sliders, 'activate', 'clear' etc. for Hotcue buttons)
• this CfgKey/string list is stored in each WBaseWidget
• each widget is registered in KeyboardEventFilter (~1600 for LateNight 16 Samplers)
• KeyboardEventFilter loads the kbd mapping file
• iterate over all registered widgets, check if the controls are in the kbd mapping
  • yes: (re)create kbd tooltip strings
  • no: clear kbd tooltip string
  • push string to widget, (re)construct tooltip
• similar method for menubar actions

The downside:
all widgets are updated even if just one shortcut has been changed.

So I tried another approach, hoping that it would it be faster (in total, ie. load mapping file, check shortcuts, update widgets):

• reload kbd mapping
• compare last/new mapping, collect changed/added/removed shortcuts
• collect affected widgets
• update affected widgets

I had to implement the compare method and store more data in KeyboardEventFilter, and it turned out that this did not shorten the total time to the extent that it justifies the additional complexity (and potential errors/inconsistency), given that shortcuts are evaluated rarely.
(current method: ~6-7ms in total, alternative: ~5-6ms, measured when changing one shortcut)
I can provide the commit if someone is interested.

IMO this is now ready for a final review.
@Swiftb0y suggestions for improving the copied code (eventFilter()) are welcome!